QRZ! Ham Radio 4

home *** CD-ROM | disk | FTP | other *** search

/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / files / tcpip / amiga / mb1705.exe / SYSOP.DOC < prev next >

Wrap

Text File | 1994-05-23 | 47.7 KB | 1,502 lines

╔═══════════════════════════════════════════════════════════════════════════╗ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ W0RLI PACKET RADIO BBS ║ ║ ║ ║ SYSTEM DOCUMENTATION ║ ║ ║ ║ ║ ║ Version 17.X ║ ║ ║ ║ May 23, 1994 ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ by ║ ║ Hank Oredson, W0RLI ║ ║ ║ ║ Edited by ║ ║ John Smith, N6IYA ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ╚═══════════════════════════════════════════════════════════════════════════╝ TABLE OF CONTENTS THE MAIL BOX PROGRAMS ...................................... 1 THE CONFIGURATION FILES .................................... 1 INIT.MB .................................................... 2 MOTD.MB .................................................... 4 DIRS.MB .................................................... 4 XLATE.MB ................................................... 5 DIST.MB .................................................... 6 FWD.MB ..................................................... 7 WILDCARDS .................................................. 11 PORTS.MB ................................................... 11 CRON.MB .................................................... 13 SERVER.MB .................................................. 14 KEYS.MB .................................................... 18 TAG.MB ..................................................... 19 CLOVER OPERATIONS .......................................... 20 MESSAGE MANIPULATION ....................................... 21 PRTLOG.EXE ................................................. 22 ERROR MESSAGES ............................................. 23 (i) THE MAILBOX PROGRAMS MBINIT.EXE initializes shared memory and the databases used by the other programs. It must be run first, before starting DESQview. SERVER.EXE is the main dispatcher for events that happen when a message arrives at the system, or happen at set times. You must have SERVER running for the system to operate properly. MBLISTEN.EXE handles the ports and directs interactions within the system. MBSTAT.EXE provides a system status display. MBSYSOP.EXE provides the sysop with interface to the system without using other system resources. THE CONFIGURATION FILES The following files are text files that contain site-specific information. Edit these files for the proper parameters for your site. In general: Within the following files fields are delimited by any number of blanks and/or tabs. Lines beginning with ";" are ignored and may be used for commentary. Blank lines delimit groups, or are ignored. A ";" placed at the end of a line delimits any trailing comments on that line. These files are read on an event basis with the exception of ports.mb, init .mb, xlate.mb and dirs.mb. These files are read at system startup and any changes will reqire the system to be restarted for changes to take place. The other files can be edited on the fly and the changes will be noticed upon the next event. The one exception is the intenal editor for ports (EP command). This will allow editing of port parameters but these are only temporary in nature and will revert to the saved value in ports.mb upon subsequent system restarts. CRON.MB - Describes actions to be taken at set times. DIRS.MB - File directory area definitions. DIST.MB - Bulletin distribution lists. FWD.MB - Message routing information. HELP.MB - Help command text. INFO.MB - Text of the "I" command. System information. INIT.MB - Information about the system owner. KEYS.MB - Passwords for remote sysops. MOTD.MB - Text of the login message. NEWUSER.MB - Text sent to user at their first login. PORTS.MB - COM port definitions. SERVER.MB - Descibes actions to be taken when a message arrives. TAG.MB - Your message "signature". TEXT.MB - Various configurable prompts, messages, etc. XLATE.MB - Designator translation lists, file-by-BID list, etc. REDIST.MB - Redistribution server address list. RT.INI - Round Table initialization file. (See RT.DOC) (1) The following are created and maintained automatically by the MailBox: BID.MB - Bulletin ID database. MAIL.MB - Message database. WP.MB - White Pages database. YYMM.LOG - The log files. A text file that contains the user log. YYMM is the current year and month. The form $x is a variable text field. The "$x" is replaced by the current value for that text. $a - Number of active MailBox tasks. $B - Users home bbs. $D - The current date. $H - Hang at end of line (suppress carriage return). Use at end of line only. $h - Number of held messages. $I - Sysops name. $L - Number of the last message in the MailBox $M - Message number of current msg. $m - Number of active messages (total minus killed). $N - Number of messages on system. $n - Number of killed messages. $O - Sysops callsign. $Q - Sysops QTH. $T - Current time. $t - Current task ID. $U - Users callsign. $W - Users name. $X - Date user last logged in. $Y - Time user last logged in. $Z - Users zip code. INIT.MB - SYSOP INFORMATION The basic information about the system owner and system operation is contained in the file INIT.MB. Replace the information with your own. If you feel you need to change the various WP lifetimes, be very careful and think through the implications of any such change. Section 1 - Sysop Address Our callsign (no SSID) plus hierarchical location. Our handle. Our qth (city / town only, no advertising please!) Our postal code. W0RLI.OR.USA.NOAM Hank West Linn 97068 Section 2 - WP Global Server Information N6IYA.#NOCAL.CA.USA.NOAM (2) Section 3 - Sysop Call 30 (Number of seconds to ding the sysop page) Section 4 - WP Update Parameters Don't change these unless you have a REAL good reason. Note that 0 means "forever" ... 45 (Days old a "local user" (L) WP entry must be before it is removed) 75 (Days old a "known BBS" (I) WP entry must be before it is removed) 55 (Days old a "user of other BBS" (?) WP entry must be before it is removed) 0 (Days old a "sysop locked" (B,S,X) WP entry must be before it is removed) 50 (How often (in days) to refresh local user data to Global WP server) Section 5 - Local System Parameters Change these to suite the conditions at your location. 7 (Days until Bulletin stale. Marked "O".) 2 (Days until NTS msg stale. Marked "O".) 13 (Days until Personal msg stale. Marked "O") 30 (Days a BID remains valid) 2 (Number of times a message can loop before being held) 20 (Days old for incoming bulletin to be held. Marked "H") 50 (L command max to list) 160 (Limit on number of lines in REQWP response) 5000 (Size limit for WP Update message) YES (Replace hloc on msg with info from @ BBS in WP) 256 (Max files for W commands) YES (B command returns to node instead of disconnect) 6 (Max # tasks that will forward at one time) NO (Use hierarchical locations with leading "#") YES (Normalize all headers) 20 (Size of compressed batch, in k bytes) YES (Use compressed batch forwarding) Section 6 - DesqView API New for version 17.x is the ability to use the Desqview API to handle many of the mailbox tasks. At the bottom of the file are 9 new lines that are to be added. YES (Use Desqview specific calls) (Note: You may choose any favorite text editor for the functions below. It has been tested with Personal Editor and the DOS Edit program that comes with the later versions for MS-DOS. PE amd LI are the Desqview keys for Personal Editor and List.com and are not supplied with the package.) PE (Desqview key that defines the text editor for send message commands) (Note: [..] will disable this function. If you are using PE then set the DV window to come up in full screen mode.) PE (Desqview key that defines the text editor for reply message command) (Note: [..] will disable this function) LI (Desqview key that defines the program to read messages. (Note: [..] will disable this function) (3) (Note: The Desqview keys defined below are only examples. You will have to choose the keys that you desire based on your Desqview setup. For example: in the standard Desqview 386 setup MF calls Quarter Deck Manifest.) ML (Desqview key that defines MBLISTEN.EXE) MU (Desqview key that defines MBUSER.EXE) MF (Desqview key that defines MBFWD.EXE) MT (Desqview key that defines MBSTAT.EXE) MS (Desqview key that defines MBSYSOP.EXE) Section 7 - Control Keys F (Control character to kick user off of system.) E (Control character to return from talk mode.) E (Control character to interrupt user and talk.) (Note: these keys can be defined as the function keys F1, F2 etc.) (Note: a little history...orginally called the "Cat Keys". During) (orgination of the program 2 new cats were aquired and had a propensity) (to walk on the keyboard. The odds of a single key being depressed) (during these excursions was extremely high and as such could and would) (place the bbs in the strangest places. Hence the orgination of 2 key) (combinations to perform these functions...js...) MOTD.MB - THE LOGIN MESSAGE The login message is contained in the file MOTD.MB. Varible text fields can be used in MOTD.MB, just as in TEXT.MB. This file is also a good place to inform users of any changes that have taken place on the system or the network. Example MOTD.MB Hello $W, Welcome to the $O Mailbox, part of the OPEN Network. This system is Operated by $I in $Q, Oregon. You last connected at $Y on $X; your Home BBS is $B Type H for Help. Type I for Information about this system. Note: The RT Server is now on line at Node WLINN. Connect to the switch and enter RT. Have fun and enjoy! $I DIRS.MB - FILE DIRECTORY AREAS The first field is a single character path ID, followed by "D" if downloading is allowed, and "U" if uploading is allowed. The second field is the path, with trailing '\'. The third field is the name of the path, as shown to the user. Example DIRS.MB ADU \bulls\arrl\ ARRL Bulletins BDU \bulls\baycom\ Baycom Exchange Newsletter CD \bulls\mbdoc\ Mailbox Sysop Documentation DU \bulls\sysop\ Upload file area for sysop only files. (4) XLATE.MB - TRANSLATION, FILE-BY-BID, HOLD LISTS, ETC Each line in this section instructs the MailBox to take some action when it receives some specific kind of message. Each line has several fields. The first field tells WHAT action to take. The second and following fields tell HOW to take that action. Note that the character string matches allow wildcards (See WILDCARDS below). If more than one action applies to a given message, they take place in the order they are given in XLATE.MB. Action code Meaning B File message by BID H Hold any messages TO, FROM, or @ this callsign. HT Hold any messages TO this callsign. HF Hold any messages FROM this callsign. HA Hold any messages @ this callsign. HL Hold all locally entered messages. This include personal type messages. R <old TO> <old @> <new TO> <new @> - Address translation information. The 1st or 2nd fields may use wildcard matching (see WILDCARDS below). A single "*" in the 3rd or 4th fields means "leave unchanged". T Set time-to-live for this bulletin class. If set to 0, will kill after forwarding. Examples: b arl* \bull\arrl\ - File ARRL bulletins by BID. k sale allusa - Kill SALE @ ALLUSA after forwarding. hf wb6oco - Hold any messages from WB6OCO ht ffnet - Hold any messages to FFNET r * w0rli * - Remove the "BBS" if it is this BBS. r * worli * - Fix typical typo. r * rlimb * - Fix typical typo. r * orgb * or - Any message @ "ORGB" becomes @ "OR". r sysops * sysop * - Any message to "SYSOPS" becomes to "SYSOP". r all amsat amsat allusa - Bulletins to ALL@AMSAT become AMSAT@ALLUSA t wx pdx 2 - Bulletins to WX@PDX will go away in two days. t * amsat 10 - Bulletins @AMSAT will go away in ten days. Note: These are typical examples and for the local area only. Configure to your specific area, callsign and alias as needed. In addition, corrections can be made to other traffic coming thru the system to correct user initiated mistakes. Ultimately, it is the sysops responsibility to inform the users and/or sysops that these errors are occuring and that corrective action needs to be taken. (5) DIST.MB - DISTRIBUTION LISTS The file consists of any number of lines, where each line has: TO AT call1 call2 call2 ... If a message matches the TO and AT (with wildcards - see WILDCARDS below), then it will be distributed to the calls listed on the rest of the line. There can be up to 14 calls per line. If you have more than 14 calls for a single distribution, simply create two lines. Distribution lists are cumulative. Note that if you put your own call in the list, the message will not automatically kill until after you have read it. It will be "distributed" to you. The message is not forwarded to the stations in the list any special order. If a station is busy then the MailBox will try again the next hour. An "L ;" listing of a message with a distribution list shows the sysop the status of forwarding to each station on a second "cc:" line. The calls to which the message have been sent have an asterisk before them. Distribution list example: * allor ka7agh n7chr kb7dbd w7dcr n7dxt wa7shp wa7sjn n7vyn * allors w7dcr n7dxt wa7shp * allusa ka7agh n7chr kb7dbd w7dcr n7dxt wa7shp wa7sjn n7vyn * allusa w7xyz w7xyz aa7qq * allusw ka7agh n7chr kb7dbd w7dcr n7dxt wa7shp wa7sjn n7vyn * amsat ka7agh n7chr kb7dbd w7dcr n7dxt wa7shp wa7sjn n7vyn * open ka7agh kb7dbd wa7sjn * pdx ka7agh n7chr kb7dbd wa7shp wa7sjn n7vyn * or ka7agh n7chr kb7dbd w7dcr n7dxt wa7shp wa7sjn n7vyn * sunami n7hae w7vtw * wwgb ka7agh n7chr kb7dbd wa7sjn n7vyn sysop * w0rli * net ve3gyq w3iwi wb1dsw w0ljf k0jjv ad8i * usa wa7sjn n6iya w5xo Things to note: A message addressed SYSOP @ OR will hit two distribution lists, "sysop *" and "* or". It will thus get all the calls in both lists as it's distribution. From version 16.8 there will only be one forward of a message with multiple lists. It is possible to distribute messages to H components such as USA, OR and WA as these are treated as seperate items. H components are not considered for the domain in which the station exists. To forward messages to other domains the syntax SB target @ XX.XX will use the H component to move to other domains and then distribute on the @XX component. The distribution list file is read "fresh" for each message, thus you can alter it "on the fly" while the system is running, IF your text editor supports file sharing properly. If it does not, you may get "sharing violation error" when attempting to write the file back out from your editor. (6) In fwd.mb, the callsign from the dist.mb list must be prefixed with "$" to cause the bulletins to forward. This is done so that you can forward personal messages first, bulletins last. FWD.MB - AUTOMATIC FORWARDING The file FWD.MB contains information that drives the automatic forwarding of messages. If the file does not exist, no forwarding is done. Forwarding is done when some item in CRON.MB triggers it, or by sysop command. FWD.MB consist of a number of lists, and a "forwarding script" associated with each list. Each list has the information for one MailBox to which you will forward. The script associated with the list tells your MailBox how to connect to the MailBox you will forward to. The list contains information that describes which messages will forward to that MailBox. Each list is terminated by one or more blank lines. A line starting with semi-colon will be ignored, you can use this for commenting your fwd.mb. Trailing space plus semi-colon can be used to add a comment to the end of a line. I have included an example FWD.MB file in the release package. The overall structure of FWD.MB is thus: Script1 List1 Script2 List2 ... etc. Routing lists. Each list has any number of callsigns, designators, or sublists. There can be up to 24 callsigns or designators on each line. Thus, a list will look like: ntsmn ntssd w0qrm k0cj or: ntswa 98* w7xyz aa7abc @hf.fwd (7) Format of the list header. Call: <callsign> Group: <group 1> <group 2> ... (note: not to exceed 6 characters in length) Port: ID Pre: <command> Post: <command> Con: <command> Timeout: <seconds> Message: <max size> Batch: <max size> Notes: If a Port: is not specified, any free switch port will be used. If a Batch: <size> is not specified, the default batch size from INIT.MB is used. In addition if Batch: <size> is set to "0" then compressed fwding will not occur for this connect. The Connect Script ("Con: <command>") can have the following commands: For a CLOVER normal link: CN CALL For a CLOVER robust link: CR CALL For a direct connect to the MailBox you wish to forward to: CC 3 N7HAE <- Means "downlink to n7hae from the node on its port 3" To connect to a distant MailBox running the g8bpq switch, when you are using the g8bpq switch also just connect to that MailBox call: NC WA7SJN Some more examples: NC W6NR-11 NC N7EQN-10 via A6DIG Summary of script items in FWD.MB CN call - Connect TO this call using normal CLOVER link. CR call - Connect TO this call using robust CLOVER link. NC call - Connect TO this call FROM a node. X n cmd - Control transceiver before or after connect. S text - Send this text. R text - Receive this text. R! - Receive any text. For additional Pre: and Post: commands for the HAL PCI-4000 CLOVER board, and for transceiver control commands, see the section on CLOVER. Pre: items give TNC commands to be executed BEFORE the connection: Pre: retry 10 Pre: maxframe 3 Pre: frack 8 (8) There is an additional command that can be issued using the pre: format This is the W command [wait]. This value is expressed in seconds and can be used to delay the processing of further commands while the system is processing a previous command. An example is wait period introduced to allow radio to go to another frequency. Pre: W 2 < wait 2 seconds before processing the next command. Post: items give TNC commands to be executed AFTER the disconnect: Post: retry 3 Post: maxframe 7 Post: frack 3 Be very careful using Pre: and Post: items. The MailBox assumes that the TNC is setup in a "standard" manner. If you change CR, CP, or SE in a script, it could cause problems. Timeout:, Message:, and Batch: items are used to place limits on what will forward when the list is used. Message: nnnn - Will limit the size of messages forwarded. Examples: Message: 20000 Keep any message larger than 20k bytes from forwarding. Batch: 20000 If batch compression is in use, set batch size to 20k bytes. Pre: S and Pre: R items are used to forward in unusual situations, so that you can handle networks which do not use NET/ROM . S and R items come in pairs: An S item is a line to send: Pre: SBBS An R item is the expected response: Pre: R#SBAY1:N7EQN-10} Connected to #WWORM:WB6FFC-1 In the case that ANY response is valid use: Pre: R! (9) As an example, the script for W0RLI in Santa Cruz using NET/ROM to connect with KA6IQA in San Diego might be (using all the possible script features). Call: ka6iqa Group: south socal Port: b Message: 2000 <- Don't forward messages larger than 2K. Timeout: 240 <- Use 4 minute timeout for this forward. Batch: 0 <- Do not use compression for this forward. Pre: retry 10 <- Tough path, retry a lot. Pre: maxframe 3 <- And don't send very many packets. Post: retry 3 <- Put things back to normal after this forward. Post: maxframe 7 <- Ditto Con: nc w6amt-1 <- Connect to the local NET/ROM backbone node. Con: nc w6amt-3 <- Connect to the NET/ROM closest to KA6IQA. Con: nc ka6iqa v w6amt-4 <- Connect to KA6IQA. ka6iqa <- Forward messages TO or AT KA6IQA. 91* <- Forward zip codes starting with 91. $ka6iqa <- Then forward bulletins to KA6IQA. Sublists. At any place in the FWD.MB file you can refer to another file. The contents of the file is treated exactly as if it was in the FWD.MB file. This feature is very useful when you have several alternate paths to a given location. FWD.MB need only contain the connect Script for each different path, and a list containing a reference to the file which contains the list contents. A sublist file is given by a line starting with "@". The rest of the line is the device, path, and file name of the sublist. Example: Call: n4chv Port: c Con: NC N4CHV N4CHV @C:\BBS\HF111.FWD @C:\BBS\SILICON.FWD Call: w6cus Port: d Con: NC W6CUS-1 NI6A @C:\BBS\SILICON.FWD Entry qualifiers. A qualifier is appended to the line it affects. There is one qualifier at this time: " /TSSEE" where SS is the start hour and EE is the end hour. This qualifier causes the line to be ignored if the current time is not within the time window. (10) WILDCARDS AND SPECIAL "CALLSIGNS" IN LISTS. When the designator in FWD.MB is compared to the TO or @ BBS call, the characters '?', '*', '@', '!', '+', '"' in the designator act as wildcards. Wildcards matches are supported in many places. With wildcards we match with more than a straight comparison. Special characters in the pattern are: * -- Matches 0 or more characters of any type. @ -- Matches any alpha character (a..z, A..Z). ! -- Matches any digit (0..9). + -- Matches any alphanumeric character (A..z, A..Z, 0..9). ? -- Matches any single character. " -- Escape. The next character in the pattern must match the character in the target exactly. Wild cards will not be interpreted. Examples: 97* -- Will match anything starting with 97 such as 97068, 97123, 97ABC, and 97. 97??? -- Will match anything that starts with 97 and is 5 characters long. 97068 will match but 9706 will not. 97!!! -- Will match anything that starts with 97 and has 5 digits. 97068 will match but 97ABC will not. @!@@@ -- Will match a 5 character US callsign such as W0RLI, N6IYA, etc. VE!@@@ -- Will match standard Canadian callsigns. "!"* -- Will match *! !* -- Will match anything that starts with a digit. Note that within FWD.MB, you cannot use @ as the first character, since @ is used to branch to another file. This will be changed in some future release of the MailBox. The callsign "*" is special. Putting it into a list means for forward all messages not addressed to users of the system. It is a shorthand way to set up a "local" bbs, which forwards all outgoing traffic to a single "full service" bbs. If you use this feature, there should be NO other callsigns or designators in the list. To forward bulletins, the designator that must be used is the callsign of the station (as used in dist.mb) with "$" prefixed to it. If you had "w0rli" in dist.mb, you would put "$w0rli" in fwd.mb. This allows you to position the bulletin forwarding in the forwarding sequence in any way you like: first, last, somewhere in the middle. PORTS.MB - PORT DEFINITIONS There must be a definition for your printer: Printer type can be one of LPTx, COMx, or NONE Examples: Printer NONE Printer COM5 Printer LPT2 (11) The Console definition has been eliminated in version 17.4. It is redundant as mbsysop is always running. For each port available to the MailBox, there must be a definition. The first field is the port type: SWITCH - This port has a G8BPQ node virtual TNC connected. PCI - This port is a HAL PCI-4000 card. The second field is the pot indentifer of the first com port that can be used for forwarding or in terminal mode. The 3rd field is the number of the first COM port as defined by the ytnc configuration in your autoexec.bat file. The 4th field is the number of COM ports to use for the mailbox. Further fields are used for ports that require more information. The HAL PCI-4000 card requires two file names: the DSP microcode and the Control Processor microcode. Examples: SWITCH A 1 1 Is Switch port, using 1 port (A) and start with COM 1. SWITCH G 2 12 Is switch port, using 12 ports (G-R) and start with COM 2. PCI C 360 \pcc\pcc.lod \pcc\pcc.s28 Non-Switch CLOVER port with board loaded at address 0360H and load the the files PCC.LOD and PCC.S28 at start up. This line is followed by information about how the port is to be used: Watch Monitor - See monitoring. Watch User - See what user is doing. Watch Commands - See tnc commands. BBS Only - Only stations marked as BBS may connect. Calls Legal - Only "legal" callsigns may connect. Calls Any - Any callsign may connect. Compression On - Use compressed batch forwarding, if possible. Compression Off - Do not use compressed batch forwarding. Timeout xxxx - Connect timeout, in seconds. DTimeout xxxx - Disconnect timeout, in seconds. Errlimit xxxx - Number of command errors allowed before user disconnected. Init xxxx - Command to be sent to TNC at startup. Discon xxxx - Command to be sent to TNC at user disconnect. Connect xxxx - Command to be sent to TNC at user connect. Note: "Init", "Connect", and "Discon" commands are handled in the same way as Pre: and Post: commands in FWD.MB, see the FWD.MB documentation for details. See also the section on CLOVER for further information on HAL PCI-4000 commands. (12) Examples: SWITCH A 1 9 - Switch port, using 9 ports (A-I) Starting with COM 1 Watch Monitor - Turn Monitor on Watch User - Monitor user Watch Commands - Echo TNC Commands to screen BBS Only - Only BBS can use this port Calls Legal - Accept only legal calls Compression On - Use compression Timeout 300 - Timeout port after 360 seconds of inactivity DTimeout 30 - Timeout port after 30 seconds if <DACK> not received Errlimit 5 - Allow 5 command errors before disconnect Init echo off - Turn ECHO off Init flow off - Turn FLOW off PCI B 360 \pci\pci.lod \pci\pci.s28 Load CLOVER board as PORT B address 0360H Watch Monitor - Turn on Monitor Watch User - Montior User Watch Commands - Echo TNC commands to screen BBS Only - Only BBS can use port Calls Legal - Accept only legal calls Compression On - Use compression Timeout 180 - Timeout port after 180 seconds of inactivity DTimeout 10 - Timeout port after 10 seconds if <DACK> not received Errlimit 5 - Allow 5 command errors before disconnect Init BF - Set board fast bias Init R 9 - Set retry count to 9 Init S 0 - Set chat threshold to 0 Discon X 1 SC1; - Upon disc send resume scan command on COM 1 CRON.MB - TIMED EVENTS The file CRON.MB describes timed events to SERVER.EXE Each line in CRON.MB takes the form: <time clause> <action clause> The time clause takes one of two forms. At H1 At M1 This causes the action to take place at a specific time. From H1 to H2 Each M2 At M1 This casues the action to take place periodically. The "Each M2" may be left out. If it is not present, "Each 60" is assumed. Note that the "At" qualification applies minutes in the "Each" period. "Each 10 At 20" for example does not make sense, since there will never be a "20th minute" in a ten minute period. However, "Each 20 At 10" does make sense, as there is a "Tenth minute" in every 20 minute period. The action clause takes one of the following forms: GM - Delete killed messages from the system. J - Save the list of recent connects. (13) Clean - Generate the WP Update message, kill old bulletins, remove stale BIDs from BID.MB. Note that you MUST have and entry for CLEAN for the system to operate normally. Tofwd - Rebulid the "to forward" list if it is full. Beacon - Send the "Mail for:" beacon on the switch ports. For the following <Callsign> and <Group ID> must be the same as specified in FWD.MB Forward Call <Callsign> - Forward to a particular station. Forward Group <Group ID> - Forward to all stations that use the group ID. Must match <Group ID> in Fwd.mb and cannot exceed 6 characters in length. Poll Call <Callsign> - Poll the callsign for reverse forwarding. Poll Group <Group ID> - Poll the <Group ID> for reverse forwarding. Must match <Group ID> in fwd.mb and cannot exceed 6 characters in length. Import <file> <format> - Attempt to import messages from a file. See SERVER.MB for details of <format>. Run <program> - Run a program in a Desqview window as defined by the DV key. Examples: To Import messages from the file MSG.IN at ten minute intervals starting at minute 5 all day: from 0 to 23 each 10 at 5 import msg.in h8 SERVER will attempt to import at 00:05, 00:15, 00:25, etc. To save the g8bpq node list every 20 minutes: from 00 to 23 each 20 at 7 run S1 (Formerly BPQNODES.BAT>NUL) Every hour, at 23 past the hour, forward to group CLOVER. from 00 to 23 at 23 forward group clover See file CRON.MB for more examples. SERVER.MB - DEFINITIONS FOR SERVERS SERVER.MB describes what actions to take when a message arrives at the system. It contains information that drives Export/Import of messages and the running of external servers such as FILEX. If the file does not exist, no Export/Import is done and no servers are run. (14) In version 17.x you will be required to setup external servers as Desqview programs (See Desqview section in Install.doc). The Desqview keys defined in the ADD A PROGRAM section will be used to define the server and placed on the line instead of the path and program name. For example: In Desqview the Filex Server has been defined as S2-PIF.DVP. The keys to initiate the program are S2 in the Open a program menu in Desqview. The line in SERVER.MB that used to be: filex.out 8 \mbexe\filex.exe filex.in 8 filex reqdir reqfil will now read: filex.out 8 S2 filex.in 8 filex reqdir reqfil External Server operation: Automatic Export/Import of messages. There are three kinds of servers S1 does only export. S2 does export then runs a program. S3 exports, runs a program, then imports. The information required in SERVER.MB, and the type of processing done, is slightly different for each type. S1 Server: An S1 server checks the message against the list, and exports it if there is a match. This is typically done to archive all messages: You specify two fields in SERVER.MB for an S1 server: out_file out_format Example: arch.msg rh8 * S2 Server: An S2 server exports in the same manner as an S1 server, but runs a program after the export. You specify three fields in SERVER.MB for an S2 server: out_file out_format program_name Example: check.msg rh8 \utils\headers.exe * (15) S3 Server: An S3 server exports, runs a program, then imports. A complex server first exports any messages that match the designators in the designator list. Then the server process is run. Then any generated messages are imported. Note that, unlike a simple server, all three functions always take place. Thus a complex server can function (for example) to transfer messages both ways between the MailBox and smtp. A list like the one below, placed into SERVER.MB, is required to define a complex server. If the server file extension is .EXE or .COM, then COMMAND.COM is not loaded. If the server file extension is .BAT, then COMMAND.COM is loaded, and you must take it's memory requirement into account. Most servers are S3 servers. You specify five fields in SERVER.MB for an S3 server: out_file out_format program_name in_file in_format Example: echo.out h8 S2 echo.in h8 echo Available format modifiers are: 8 - Use RFC-822 headers. H - Include the BBS message headers. On import, there will be no blank line between existing headers and the new header created with the new message. O - Use the old style "standard" (WA7MBL) export/import format. R - "Read only" - do not kill the message, or mark it as forwarded when it is output to the server. If no modifier is given, then ONLY the message text is put into the file. Wildcards and special "callsigns" in lists. See WILDCARDS above for a description of how to use wildcard characters. Sublists. At any place in the SERVER.MB file you can refer to another file. What happens is that the contents of the sublist are treated exactly as if they were in the SERVER.MB file. A sublist is given by a line starting with "@". The rest of the line is the device, path, and file name of the sublist file. File formats. The following is an example export file produced using format H8. Things to note about this file: 1. There is a blank line following the RFC-822 header, and another following the MailBox header. (16) 2. The special header item "X-msgtype" is used to show whether the message is a Bulletin, is Personal, or is an NTS message. 3. The special header item "X-BID" is used to show the BID, if the message has one. 4. The file can contain multiple messages. Date: 12 Mar 89 17:09 <- Date at originating MailBox Message-ID: <8988@N6IYA> <- Message number at orig MailBox X-msgtype: P <- Message type (B, P, T) X-BID: 1234_N6IYA <- BID, if the message has one. From: N6IYA@N6IYA <- User at orig MailBox To: ECHO@W0RLI.OR.USA.NA <- Full location as sent Subject: Testing path turnaround. <- Message title <- Blank between RFC-822 hdr and MailBox hdrs R:890312/1722z @:W0RLI.OR.USA.NA West Linn #:3571 Z:97068 R:890312/1709z @:N6IYA.CA.USA.NA Felton #:8988 Z:95008 <- Blank between MailBox hdrs and text. Test message. <- Message text. ../EX <- ".." added, not there in actual format It appears that there will be a large number of servers created. These are servers I have heard about. Some are ready for use, some are in the planning/coding stage. ECHO - "echo" the message back to sender for path testing. REQDBF - Database server by K0ZXF. FILEX - "File eXchange". Upload, Download, directory listings. REQDIR - Request directory information. The FILEX server handles REQDIR. REQFIL - Request a file. The FILEX server handles REQFIL. REQQSL - Request qsl manger info for dx callsign. REQWP - Request WP information. Remote access to the I, I@, IH, and IZ commands. RLIMON - Automated sysop functions from KJ4LQ. REQQTH - Request name/address for callsign. REQCB - Callbook info from the J-Comm or RT Systems databases. SMTP - smtp/BBS message interface. Here is an example for a user-written server, using only DOS batch commands. This server will print selected messages as they arrive. 1. In the distribution lists for any messages you want printed, add an extra callsign PRTIT. (17) 2. In SERVER.MB add the lines: PRTIT.OUT H8 PRTIT.BAT PRTIT Where PRTIT.BAT contains: PRINT PRTIT.OUT DEL PRTIT.OUT KEYS.MB - PASSWORDS FOR REMOTE SYSOPS Sysop passwords for the MailBox. Designed by Geert Jan de Groot, PE1HZG, Eindhoven, Holland Remote sysop is a nice way to split the work involved with managing a BBS among several people. However, in the past, some crooks used the calls of some (remote) sysops and erased all files... I added a netrom-like verification procedure to check if a remote sysop is really who he says he is. The procedure is as follows: Each 'trusted person' has his own personal key, which consists of an array of 10 by 10 random letters and numbers, like this: Key for: PE1HZG 01234 56789 0 tBixT 03ytR 10 9yD6s HfC0c 20 ze28q 70nL4 30 7OczX 1fEdW 40 6R8BU cao07 50 OWJ1m lTo2q 60 XLHGl NCDdF 70 2wXUO rjwDL 80 uh7P4 fsYiO 90 mQPjY zXxAM On the @ command, the BBS gives 3 lines of 8 numbers, like this: 2354 - L#4912 - PI8ZAA-BBS > @ (user gives sysop command) 2 55 26 46 24 52 79 77 (BBS verification ) 41 23 94 23 86 56 54 23 75 69 3 97 77 49 64 38 il0aqJLw (user response to 1st line) N#182 - L#4912 - PI8ZAA-BBS > (success - sysop prompt) A remote sysop translates ONE (just random, first, second or third) line into the matching characters using his personal key. Which line matches, does not matter. If the sent response-string matches, the user is who he says he is and goes to remote sysop status. If not, nothing happens. (18) Bad guys who monitor the BBS, see an answer to 3 possible questions, and don't know what line matches the response string, so they can't re-build the key matrix owned by the remote sysop. This, of course, only works if remote sysops randomly pick the first, second or third line to translate. (However, using statistics, people can deduce the original key if they have enough data. Crypt wizards say it may take 100 sessions before such an attempt may be successful. If you go sysop 1 time a day at most, and change keys every 2 months, they should not be able to get sysop status.. time will tell!) In the BBS, there is a file called KEYS.MB which has records of this format: PE1HZG tBixT03ytR9yD6sHfC0cze28q70nL47OczX1fEdW6R8BUcao07OWJ1mlTo2qXLHGlNCDdF2wXUO Each remote sysop has his own entry in the keys.mb file, and should have different keys. At PI8ZAA, the actual keys are generated by machine, a small basic program will do the trick. Of course, NOBODY should EVER consider downloading the KEYS.MB on air! If a person with a unknown call tries to get sysop status, simply NO response-string matches. I did this because it was easier and maybe it keeps the bad guys puzzled.. If the password is a single "*", then that user may become sysop without any password being required (added by W0RLI). Note: For each station to have sysop privledges they must also be noted in WP.MB as being a sysop. Use the EU CALL command to toggle the sysop key. TAG.MB - MESSAGE TAGGING The file consists of any number of groups, where each group has: Header line <any number of text lines> . <a line containing only a period, this terminates the text> Header line <text> . etc. The header line contains a single character to indicate when to apply the tag, and a list of callsigns, (no more than 15). The character at the start of the line can be: L - Apply the tag to locally entered messages (it's your signature). R - Apply the tag to messages received from these stations. T - Apply the tag to messages sent to these stations. (19) CLOVER OPERATIONS In terminal mode there are a small number of commands you can use to control the operation of the PCI-4000 and it's radio. These commands are also available in FWD.MB scripts, and as "Init", "Connect", and "Discon" commands in PORTS.MB. CH n - Use voice subchannel n (1 to 5). CN <call> - Initiate a normal link to <call>. CR <call> - Initiate a robust link to <call>. CW <on/off> - Turn CWID on or off. RC <number> - Set CCB retry count. RN <number> - Set NORMAL retry count. RR <number> - Set ROBUST retry count. BF - Set fast bias. BN - Set normal bias. BR - Set robust bias. S <nn> - Set chat threshhold to nn (0 is normal). *** Serial port control of the radio: These commands support COM1 through COM4, at the following addresses: COM1 - 3F8 COM2 - 2F8 COM3 - 3E8 COM4 - 2E8 Note that the COM port baud rate, etc. must have been previously set (using for example the DOS MODE command), and that CTS/RTS handshaking is used. If CTS/RTS is not required, those pins must be jumpered at the PC end of the cable. Serial Port Commands "XI" command: Used to send initialize the serial port used to control a radio. XI p baud parity bits stop Example: XI 1 4800 N 8 2 Kenwood Radio Control "X" command: Used to send commands to a Kenwood radio using the Kenwood interface. X p cmd cmd ... - Send commands out serial port p. Examples: (20) Pre: X 1 FN2; -> Using COM1, tell transceiver to use memory channels. Pre: X 1 SC1; SC0; MC023; -> Start scan, stop scan, QSY to memory channel 23 before making this connect. Post: X 1 MC001; -> QSY to memory channel 1 after disconnecting. Yaesu Radio Commands "XY" command: Used to send commands to a Yaesu radio using the CAT system. XY p opcode par1 par2 par3 par4 The opcode and par are the numbers per the Yaesu CAT documentation. Bytes are sent in reverse of the order given, i.e par4 par3 par2 par1 opcode. If the CAT opcode does not require all parameters, you may leave them off. Examples: XY 1 2 12 0 0 0 -> Set radio to memory channel 12 XY 1 2 12 -> Set radio to memory channel 12 Terminal Commands The following are available only in terminal mode. T - Send test tones. I <a> <b> - Initialize the board using the PCC.LOD file given as <a> and the PCC.S28 file given as <b>. MYCALL is set, and other parameters required for correct MailBox operation are also set. I - With no file names given, defaults to using the files \PCC\PCC.LOD and \PCC\PCC.S28 < file - Read commands from file. MESSAGE MANIPULATION One problem that confronts the sysop from time to time is a message that has the wrong type, wrong distribution list or wrong address. There are 2 ways to correct this problem. 1) Use the "E" command and edit the message header. Because of the many possibilities, this command is limited in scope. For simple changes, such as "unkilling", a message , it will work. It will not create a new distribution list. It will however allow you to edit the message header to change the "TO", "@BBS", "TITLE FIELDS" and the various message status parameters. The paramaters include changing the message type (B,P or T), whether the messages is held, killed, forwarded, read or is old (H,K,F,Y,O). The command syntax is E message number <CR> T New to callsign or designator b bbs and/or HLOC designator H New message title S option (Options are BFHKOPTY) (21) Each of the above commands must be done singularily and cannot be grouped. For example: T N6HAM <cr> When finished a <CR> ends the editing session for that message. 2) To create a new message and any distribution that may be associated with the message, it will be necessary to copy the message to a file and then create a new message. Although this sounds fairly complicated it is a simple process and requires the use of 4 commands. The F, M, K and Z commands. Step 1 Convert the message to a file...to do this use the F command. F 325 TEMP.TXT This puts message # 325 into a file called TEMP.TXT in the directory of \bbs. Step 2 Convert the file into the new message....to do this use the M command. M(P,B,T) TEMP.TXT Callsign @ BBS The system will then prompt you for a title. You can enter the orginal title or one of your choosing including a blank. Step 3 Delete the orginal message with the K command. K 325 Step 4 Delete the temporary file using the Z command. Z TEMP.TXT PRTLOG.EXE - THE LOG FILE ANALYZER A utility to analyze the system created log files. This utility will process the data contained in the log files and allow the sysop to analyze the information to determine how the system is being utilized, what type and how many messages have passed through the system. Entering PRTLOG from the DOS prompt will give the sysop a menu of items on how to use the utility. PRTLOG <cr> PRTLOG outfile -opts Option: C - Report by callsign L - Detail listing D - <from> <to> - Inclusive date range. i.e. -d 920812 920923 F - <list file> - File of calls to analyze For example: PRTLOG aug.log -c <cr> will analyze the files specified by callsign. (22) PRTLOG aug.log -l will give a detailed listing of all events in the specified log files. PRTLOG aug.log will give a summary report of the specified log files. PRTLOG will prompt for the log files to be analyzed. PRTLOG TEST.LOG <cr> Log File (or enter when done:) at this point enter the name of the log file to analyzed in the format: yearmonthLOG.number i.e.: 9301LOG.1 <cr> When all the files to be analyzed are entered follow with a <cr> and the output file will be created. ERROR MESSAGES Starting in version 17.5 error messages will be displayed on the screen indicating certain system statuses. These messages are for debugging the system. If you encounter these messages please note them before attempting to do anything else with the system if they fail to go away. If they are indicated in many windows this is indicative of a system crash and server is usually not running. The messages will appeare only once in a given window after the system has attempted to a lock on a record or mail.mb 10 times every 2 seconds. If the locks cannot be accomplished and the messages appear then you should attempt the recovery process. The messages Message record nnnn locked (read) Message record nnnn locked (write) Message record nnnn locked (read/lock) MAIL.MB header locked (read) MAIL.MB header locked (write) MAIL.MB header locked (read/lock) (23)